[SIM-ENG-004] Реализовать пакетный прелоадинг кэша (Bulk Pre-warming) для Redis

Оптимизация фазы холодного старта симулятора при массовом запуске цифровых двойников

Author

Simulation Framework Systems Analysis

Published

September 28, 2026

NoteКраткая карточка задачи
  • Репозиторий / Компонент: food-stochastic-simulator / package orchestrator.
  • Тип задачи: Инфраструктурная / Оптимизация производительности (Performance).
  • Связанные документы: index.qmd (Раздел 4. Двухуровневое управление состоянием).
  • Статус: Готово к реализации

  • Описание задачи:

    Текущая реализация SimulationEngine использует стратегию ленивой загрузки (Lazy Load) состояний виртуальных холодильников при промахе кэша (Cache Miss). При одновременном запуске масштабных симуляций (до 50 000 цифровых двойников) фаза первого тика генерирует лавинообразный сброс gRPC-вызовов к внешним продуктовым сервисам. Несмотря на наличие семафора на 5000 конкурентных воркеров, это приводит к выстраиванию горутин в затяжную очередь и критически раздувает время инициализации таймлайна.

    Необходимо внедрить механизм принудительного пакетного прогрева (Bulk Pre-warming) кэша Redis до запуска основного итерационного цикла времени.

  • Инструкция по шагам:

    1. Создание интерфейса пакетного прогрева: Расширить абстракцию DBProfileLoader или создать смежный интерфейс BulkStateWarmer в пакете processes, декларирующий метод для пакетного получения стартовых срезов данных.
    2. Реализация конвейерной записи (Redis Pipeline): В классе SimulationEngine перед входом в цикл for currentVirtualTime.Before(endTime) реализовать фазу PreWarmCache. Метод должен группировать полученные стартовые стейты твинов и записывать их в Redis с помощью пакетного конвейера rdb.Pipeline(), минимизируя сетевые раунд-трипы (RTT).
    3. Оптимизация RAM-воркеров: Изменить метод processAgentTick. Если фаза PreWarmCache отработала успешно, воркер гарантированно забирает данные из Redis за одну операцию без динамического переключения на сетевой gRPC-интерфейс StateWarmer.
    4. Безопасный Fallback: Если пакетный прогрев завершился сбоем (например, таймаут PostgreSQL при bulk-выборке параметров), система должна залогировать WARN событие и автоматически переключиться на стандартную ленивую загрузку (Lazy Load), не прерывая жизненный цикл симуляции.